Community antenna television (“CATV”) networks have been used for more then four decades to deliver television programming to a large number of subscribers. Increasingly, CATV networks are used by providers to provide data services to subscribers. For example, cable modems used in a broadband cable modem termination system (“CMTS”) are capable of transmitting and receiving Internet data using the Data Over Cable Service Interface Specification (“DOCSIS”) protocol. DOCSIS provides a standard that allows network devices made by different vendors to communication with one another. In addition, different device models made by the same manufacturer can also communicate with other.
Typically, each communication device is controlled with software that performs various functions. The software typically comprises an operating system, data processor(s), communication interfaces for interpreting data received and preparing data for transmission in a particular format, and other general digital-data-related functions known in the art.
The software is typically loaded onto the device and stored in some type of non-volatile memory known in the art. The particular software file and version number is often referred to as the software ‘load’, or simply ‘load’. A device's load is typically installed at the time of manufacture at the manufacturing plant or location. Currently, many American companies are subcontracting the manufacturing of new network devices to entities that are located overseas, particularly in Asian locations, such as China.
After a batch of a given device is manufactured in China, for example, the batch is packaged for shipment and eventual sale, and loaded onto a seagoing vessel for shipment to the United States. The journey from the manufacturing plant in China to the unloading at a dock in the United States may take between one and two months, due in large part to normal practice of shipping from that region by cargo ship to keep shipping costs low. In addition, after the batch of devices has been unloaded in the United States, they are typically shipped to another warehouse and stored until the device's buyer puts them into use. Customers are typically commercial service providers, such as, for example, cable television operators that also provide data services over their network, but could also include retail customers.
Regardless of who, or what, the buyer is, the ultimate user is typically a residential subscriber that either installs, or has someone install, one of the devices at a time that can be a quite a few months after the devices were made and the software load installed. Thus, in response to fierce competition, equipment makers are constantly improving and upgrading their products. Such change to a product often includes the software load installed into a given device. New software versions for a given device may be needed just to enhance performance, or even to remedy a ‘bug’ that has been discovered to render a device unworkable.
To provide updates to devices, such as, for example, cable modems, a service provider typically maintains a configuration file corresponding to a manufacturers device. Still using a cable modem for illustration purposes (it will be appreciated that devices other than cable modems may also need updated configuration files from time to time after being placed in service at an end user's location), an identifier is sent upstream to a central location that is operated by the service provider. Typically, the identifier is the media access control (“MAC”) identification number (also referred to as the MAC address) a unique identification attribute that is permanently embedded into the MAC layer circuitry at the time of manufacture much like an automobile's unique vehicle identification number is embedded onto the chassis at the time of manufacture. Thus, every device on a network can be uniquely identified.
The MAC identification number comprises a vendor identifier, as well as serial number, model number, as well as other device related information. Accordingly, when a cable modem ranges and registers, the sequence of events also referred to as ‘boot up’, the modem transmits the MAC address to a first server, typically a DHCP server, of the service provider; the MAC address is used to determine the appropriate configuration file that should be loaded into the modem. The vendor identifier contained in the received MAC address is compared to values in a field of a database loaded on the DHCP server. When a match is found, associated information, including the configuration filename corresponding to the received MAC address is sent to the device having that MAC address. Then, the modem device sends the configuration filename to a second server, a TFTP server, which contains a plurality of configuration files, each corresponding to a different vendor.
As long as every vendor that provides devices that are used on the network manufactures only one device, this system provides acceptable functionality. However, as vendors are diversifying and manufacturing more and more types and versions of devices that are used in a DOCSIS (or similar protocol) network, each of which typically requires a unique software load, the DHCP server cannot distinguish which configuration filename to send back to the requesting device. This is the case even if different configuration files are stored on the TFTP server because the single vendor identifier can only be associated with a single vendor. This could lead to the incorrect software load being loaded onto a given device.
To work around this problem, several measures have been tried. For example, after the devices are unloaded from the vessel and shipped to a warehouse, personnel from the vendor may be dispatched to manually update the software load for every device for which a new software version has been produced. Alternatively, for revisions that are loaded after a device has been placed into service on a network, a network management system (“NMS”) periodically polls network devices to determine the current load version, and send a new filename to the device if the current load version is not the latest. Although manually updating the devices before placing them into service provides a feasible process if the number of devices that may be stored in small (typically on the order of a few hundred), as popularity of data-over-cable networks increases, the number of devices that are in the stream of commerce will proportionally increase. Thus, dispatching a vendor's engineer to manually update thousands of devices will become unfeasible. Furthermore, depending on the polling period of an NMS, a user may be without service due to an inoperable device, for a few days, or even weeks, before a new software version file name is sent to the device, which can then use the filename to download the corresponding file from the TFTP server.
Accordingly, there is a need in the art for a method for updating the software load version for a device at the time the device is placed into service, rather than waiting until a NMS polls the device as it waits to become operational. Updating at the time the device is placed into service is also desirable as opposed to sending a vendor-engineer to upgrade devices before they are placed into service, because of the obvious extra cost and because it is possible that the software load version could be upgraded again between the manual upgrade and the time the device is placed into service.
In addition, there is a need in the art form a method that facilitates using one configuration file for all devices, regardless of the vendor that manufactured a given device, and regardless of the model numbers of the devices. This would reduce the complexity of the system for obtaining the latest configuration file filename and then downloading it.